昨天我們成功把套件上傳到測試環境，在上傳到正式的 PyPI 之前，今天想介紹怎麼把我們在本地端修改的程式碼，這樣之後就能配合 Github Actions 來建立 **CI (Continuous Integration 持續整合) **，幫助我們可以自動化處理上傳到 PyPI 的流程。

檔案狀態（File Status）

在昨天我們改完程式碼後，可以在 VSCode 裡看到我們檔案旁邊多出了 U 的小字，這代表這些檔案是 Untracked Files，尚未被 git 追蹤的檔案，還不能透過他們的 diff 來偵測改動。如果是已經有commit 過的檔案有任何更動，他就會有小字 M 在檔案旁邊，代表的是 Modified Files。這邊我修改了一下 README.md 來讓大家可以看到他旁邊有小字顯示。

這兩種檔案都是還尚未提交的檔案，我們可以用 git status 這個指令來查看當前的檔案狀態：

可以看目前有兩種類型的檔案資訊：

• Changes not staged for commit:
  • 修改過的檔案或是被刪除的檔案會被放在這區，這時候的狀態還是 unstaged 的狀態，我們需要讓他變成 staged 才能對檔案進行 commit
• Untracked files:
  • 尚未追蹤的檔案，通常是這次更新才建立的全新檔案會放在這區，同樣是 unstaged 狀態，需要改變他的狀態才能 commit

要如何把這些檔案變成 staged 呢，其實 git 提供的訊息也有跟我們說，(use "git add <file>..." to update/include what will be committed)，需要用到另一個指令 git add 把這些檔案都轉換到 staged 區。通常我都是直接下 git add . 來一次處理資料夾下的所有檔案，不過我們也可以只 add 特定檔案，只要輸入對的路徑就好，例如 git add README.md，實際執行它就能看到狀態的變化：

README.md 現在到了 Changes to be committed 這一區，這也代表我們的檔案順利到了 staged 的狀態，這樣我們就能來執行 git commit 的指令。如果想讓檔案回到 unstaged，也可以透過 git 訊息提供的 git restore --staged <file>..." to unstage 讓檔案返回狀態。

git commit

確定檔案到 staged 之後，我們就能執行 git commit 來記錄我們這次的改動，注意我們可以不用把全部的檔案都放到 staged 後在 commit，可以依據自己喜好順序來進行。這次我就先來示範如何 commit 我們剛剛放進 staged 的 README.md。

如果直接輸入 git commit 的話會進入文字編輯器，預設是 vi，會需要先按 i 進入編輯模式，寫入我們要的 commit 敘述後離開編輯模式，再輸入 :wq 存擋並離開，操作可以參考 鳥哥。我自己是比較習慣這個模式，但我想滿多人不習慣的，所以也可以使用 git commit -m "你想要 commit 的敘述" 來直接寫一句敘述。

完成後我們可以使用 git log 指令來看我們到底有沒有成功 commit 到：

可以看到我剛剛提交的 docs: Add README description 有在紀錄裡面，就代表我們成功了，之後可以按 q 離開 Log。

Commit 撰寫

通常我們在寫 commit 的時候，都會希望能清楚表達這次改動做了什麼事，同時也會希望大家的格式會一樣，方便不同的工程師來閱讀，通常一個團隊會討論好規則後會一起用同一種格式。我自己是比較喜歡 {header}({Item}): {Description} 的格式：

• header：這個 commit 的性質，像是 feat 代表 功能（Features）、docs 代表文件（Documents） 等
• Item：這個改動在哪個檔案，或是哪個元件，譬如說我有個檔案叫 Player 來記錄球員相關的東西，就可以寫成 feat(Player):，如果沒有特定的話就可以不加
• Description：完整敘述這次改動的句子，會希望是大寫為開頭，如果需要補充的話也可以使用 * 註解

不管怎樣的格式，最重要的就是大家商量好，畢竟我們寫程式是活的，不會拘泥一種形式，不過也推薦這篇文章提供的內容，大家下次在 commit 也可以參考看看：

• Git Commit Message 到底怎麼寫才優美？

另外想補充一點，雖然 commit 也可以使用中文，但我們這次畢竟是寫 Open Source，會希望給世界上各國的人使用，所以還是使用通用語言英文。

git push

我們把剩下的檔案也 commit 起來，最後再用 git status 再檢查一次有沒有漏掉的檔案，如果他顯示 nothing to commit, working tree clean，代表這次的改動的檔案都全部 commit 了。接下來我們就要上傳回我們的 Github。要怎麼做呢，會需要使用到 git push 這個指令。

這樣就代表我們上傳成功了，我們可以回去 Repo 頁 看到這次改動成功上傳，也能點選 commits 看我們的 commit 紀錄。
由於這次我們還沒設定 branch 跟 remote，所以可以直接輸入 git push 就能完成，但其實他還有其他變化在之後會需要用到，之後的內容也會介紹到。

本日小結

今天先簡單介紹了基本在本地端開發後，上傳回 Github 的流程，明天會介紹如何使用 Github Actions 建立一個 WorkFlow 來幫助我們自動上傳到 PyPI。
一樣謝謝大家今天耐心地看完這篇文章，有任何問題與建議也一樣歡迎留言給我知道，明天見了，掰掰。